dgit.raspbian.org Git - git-annex.git/blob

   1 [[!comment format=mdwn
   2  username="jkniiv"
   3  avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
   4  subject="comment 12"
   5  date="2023-07-12T17:30:52Z"
   6  content="""
   7 (...continued)
   8
   9 @ewen:
  10
  11 > My suggestion for preserving backwards compatibilty would be:
  12
  13 > 1.  Move the behaviour change out of `git annex sync` and into `git annex init` (rationale: it's run once per annex/machine pair, not many times per day/week, *and* it makes the change \"new annexes only\" which is much closer to \"opt in\")
  14
  15 > 2.  From git annex version N + 1, have git annex automatically set `annex.synccontent=true` at `git annex init` of a *new* repo (ie, not just naming the local copy of the annex), and for version N+1 to N+3 (or higher) have `git annex init` issue a warning it has defaulted sync content on now (unlike earlier versions), and describe how to find out how to turn it off (unless a global git setting is making `annex.synccontent=true` the user preferred default anyway, in which case the user doesn't need a warning of a setting matching their preferred option).
  16
  17 > 3.  For any annex where `annex.synccontent` is *not* set, assume it's an older annex, and use the backwards compatible, historical, default (false) *without* issuing any warnings about \"this is going to change\" (and never change that behaviour for historical annexes)
  18
  19 > 4.  Retain `git annex sync` forever, with it obeying `annex.synccontent` (default: false, but set to true in newly created annexes by default)
  20
  21 > 5.  Remove the newly added warning in `git annex sync` entirely, and just keep the functionality of the version before 10.20230623
  22
  23 Sounds good. I like the concept of an opt-in the way you laid it out. It's well thought out.
  24
  25 > This would:
  26
  27 > 1.  Allow changing the `git annex sync` default from `metadata only` to `full content` in a \"new usage, opt in only\" way
  28
  29 > 2.  Provide a clear path to opt out, and a clear path to opt in existing repos to match
  30
  31 > 3.  Avoid needing to issue warnings to users on every run of a very core command until they set config
  32
  33 > 4.  Avoid breaking existing usage, and use cases
  34
  35 (Yes, that warning is annoying to say the least.)
  36
  37 I'm willing to accept some breakage to my workflows but I'd rather still see a separate
  38 `git annex add`, `git commit -m ...` and \"sync metadata with one command\" workflow being supported.
  39 The name of that sync command is not that important for me but I understand why it is for you.
  40
  41 > The git annex \"meta data sync\" dance (which effectively allows `git push` into a repo that has a working directory attached, something that is normally otherwise difficult) was great, and the thing which made git annex attractive to me over other options.  It'd be a shame to render that great functionality unreachable without unwanted \"some users wanted this, so all users must have this\" functionality.
  42
  43 I agree to the strongest degree. I'm not a very good git user, but the core parts of git-annex
  44 like `add` and `sync` have made me feel comfortable to a greater extent than the porcelain of core git.
  45 I'm sure I can adapt to newfangled ways of doing my routine things with git-annex but as on \"old dog\" I'd
  46 rather not adopt those new ways if I can avoid it.
  47
  48 """]]